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ABSTRACT 



Back door packet communication between a workstation on 
a network and a device outside the network is identified by 
detecting packets that are associated with communication 
involving devices outside the network, and identifying 
packets, among those detected packets, that are being sent or 
received by a device that is not authorized for communica- 
tion with devices outside the network. 

19 Claims, 4 Drawing Sheets 
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DETECTING UNAUTHORIZED NETWORK associated with communication with an external device are 
COMMUNICATION detected. For detected packets associated with communica- 
tion with an external device, a determination is made (e.g.. 
BACKGROUND by examining hardware addresses in the packets, or watch- 
This invention relates to detecting unauthorized network 5 * n g f° r packets indicating that a non-authorized device is 
communication. advertising routes, or watching for redirect messages being 
As seen in FIG. 1. workstations 18 in an internal local area SCDt by a non-authorized device) whether or not the corn- 
network (LAN) 20 may communicate with the world outside ""^cation is authorized. 

the LAN via authorized gateways 22 that are connected, on 10 Other aspects and features of the invention include the 

one hand, to the LAN. and. on the other hand, to a dedicated following. The detecting includes comparing address infor- 

or dial-up telephone line 24. The gateways may be set up to ruation in the packets (e.g., logical network addresses, such 

prevent unauthorized communication between the LAN as & addresses) with address information associated with 

workstations and devices located outside the LAN (e.g.. a devices that are part of the internal packet network to 

device 26 connected to another LAN which is reached via determine if the packet involves communication only 

another gateway 27). Unauthorized communication may still between devices that are part of the internal packet network, 

occur inadvertently or intentionally when a LAN worksta- Th e address information associated with devices that are 

tion 28 is connected directly to the outside world. The same part of the internal packet network is stored in a look-up 

is true in situations where a LAN has no authorized gateway 20 table. 

to the outside world. The hardware addresses that are examined are hardware 

For example, a LAN workstation that includes a modem addresses of network interface cards. The address informa- 

hooked to a outside telephone line 30. may serve as an tion mal *s used for comparison is address information 

unauthorized "back door" that may pass packets back and ^ (stored in a look-up table) of devices that are authorized 

forth between the outside telephone line and the LAN. To conduits for communication with external devices, 

eliminate back door communication. LAN administrators The packets are stored temporarily in a look-ahead buffer, 

sometimes make a physical inventory of workstations to Information about the non-authorized communication is 

determine whether any of them are connected to the outside reported for use by another process, which may. e.g.. raise 

world by a path other than through the authorized gateways. 3° an alarm or obstruct the passage of the non-authorized 

Referring also to FIG. 3, a packet constructed in accor- v packet 

dance with the so-called internet protocol (IP) protocol In an internal packet network of the kind in which none 

includes an IP portion 69. The IP portion has an IP source of the devices are authorized conduits for communication 

address 74 which identifies the source device, and an IP 35 with external devices, an event may be logged with respect 

destination address 76 which identifies the target device. to packets intended for communication with an external 

While the packet is being communicated within an internal device even without checking the hardware addresses in the 

network, the packet also includes a hardware destination packets. 

address 72 (e.g.. the hardware address of a network interface Among the advantages of the invention are that back door 

card, or NIC) which identifies a destination device within the 40 communication may be effectively identified in a simple 

network by an address that is unique at least within the waVt The system wor ks automatically. The scanner may be 

internal network. a passive device. The tables may be built easily without 

Referring again to FIG. 1. a packet sent by workstation 18 requiring a detailed knowledge of hardware addresses, 

includes the IP address of workstation 18 as the IP source 45 Other advantages and features will become apparent from 

address and the IP address of the target device as the IP what follows, 
destination address. If the target device is within the internal 

network, the hardware address of the target device is BRIEF DESCRIPTION OF THE DRAWINGS 

included as the hardware destination address 72. If the target nGS laaA2m block ^ of a netW ork. 

device is not on the internal network* for example device 26. ^ , 

the hardware address of the NIC in gateway 22 is included nG ' 3 . 1S a cUa S ram * a P 0 * 00 of a ^ ackct 

as the hardware destination address. In this latter case, the ^^j. 4 is a block diagram of a portion of a packet scanner. 

gateway removes the hardware addresses from the packet FIG. 5 is a flow diagram. 

and forwards it to gateway 27. Gateway 27 adds to the 55 

packet the hardware address of device 26 as the hardware DESCRIPTION 

destination address 72. As seen in FIG. 2. internal LAN 20 includes a physical 

communication medium 40 (such as twisted pair wiring. 

SUMMARY optical fibers, or coaxial cable) that interconnects worksta- 

In general, in one aspect the invention is used with 60 Hons 18. 42. 44. In each workstation 18. the interconnection 
devices mat are coupled by a communication medium to. is made via a network interface card (NIC) 46. Operating 

form an internal packet network, at least one of the devices system software 48. such as Microsoft Windows NT®, 

not being an authorized conduit for communication with running on the workstation and in a network server 50 

external devices that are not part of the internal packet 65 implements network packet communication, 

network. In the invention, packets are observed while pass- The network software is layered. The lowest layer, 

ing on the medium. Based on the observation, packets medium access control (MAC) 54. manages the operation of 
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the NIC to achieve the communication of physical bits on 
the communication medium. The NIC in each workstation 
has a hardware address 58 that is unique at least among the 
devices connected in the internal LAN. The hardware 
address may be set manually using physical switches or 
manually or automatically using software switches. As seen 
in FIG. 3. the hardware address may be used as a hardware 
destination address 72 or a hardware source address 70 
within a packet 

f The packet also includes a network layer source address 
74 and destination address 76 (for example. IP addresses). 
An IP address is a logical address which specifies a device 
whether or not located on the internal LAN. An TP address 
may be of the form 206.8.142.10 where the higher order 
elements (e.g.. 206.8.142) of the address hierarchically and 
globally identify the address of the LAN. and the lower 
•L order elements of the address (0.10) identifies a particular 
device on the LAN. A network mask (e.g., 255.255.255.0) 
may be provided for masking the address, leaving only the 
elements that identify a network. This enables a determina- 
tion whether a particular addressed device (e.g.. 0. 10) is part 
of a particular addressed network (e.g.. 206.8.142). 

Referring again to FIG. Z to identify packets which may 
be passing via a back door 28. a packet scanner 80 is 
connected to the internal LAN medium 40. The packet 
scanner may be iinplemented as a workstation similar to the 
other workstations on the LAN but with additional software 
to perform the scanning operations. 

Referring to FIG. 4, during scanning operations, the MAC 
of the packet server operates in a so-called promiscuous 
listening mode in which it places, in a FIFO look-ahead 

buffer, every packet PI, P2 that appears on the network 

Tnf«*i»m The look-ahead FIFO buffer is provided by the 
MAC layer to make incoming packets available to the layer 
above it 

A layer of software 83 (called the VPN layer and dis- 
cussed in Alan J. Kirby et al.. U.S. patent application Ser. 
No. 08/585,765, filed on Jan. 16, 1995 now abandoned in 
favor of Ser. No. 08/946,941 filed on Oct. 9, 1997) looks, in 
turn, at each of the packets in the look-ahead buffer on a 
FIFO basis. 

The VPN software layer maintains two tables. One table 
84 holds a list of subnetwork addresses 86(e.g„ 8.142) 
which represent internal logical networks which are served 
by the physical network medium to which the packet scan- 
ner is connected. Note that, although each of the devices mat 
is physically connected to the physical network medium 40 
(FIG. 2) has a unique hardware address, the devices may be 
grouped logically into internal logical networks each of 55 
which may include a subset of all of the physical devices. A 
second table 88 lists the hardware addresses 90 of only 
authorized gateways connected to the physical network 
medium. 

As seen in FIG. 5. during the scanning loop, after getting 
(90) the next packet from the look-ahead buffer, the VPN 
layer compares (92) the source and destination IP addresses 
with subnetwork addresses in table 86 to determine if the 
packet is one that both came from and is intended for devices 
which are within one of the internal networks. If so. it is 
assumed that the packet did not pass via a back door and the 
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packet is disregarded for further purposes of the scanning 
loop. Then the next packet is fetched from the buffer 

If neither of the source or destination IP addresses are 
associated with internal networks (93). the packet should not 
be passing on that subnetwork and an event is logged. 

Otherwise, one and only one of the D? addresses must be 
of a device not associated with the internal networks; which 
one has already been determined in steps 92 and 93. For the 
IP address of the device that is not associated with the 
internal networks, the VPN layer compares (96) the corre- 
sponding hardware address with hardware addresses held in 
table 88 to determine if the packet came from or is intended 
for (depending on the particular case) a device that is one of 
the authorized gateways. If the address is in the table (result 
of the test is "yes" 99). then the packet is assumed not to 
have passed via a back door. 

Otherwise, if the hardware address does not match any of 
the hardware addresses in the gateway table, it is assumed 
that it passed or is going to pass via a back door. The VPN 
layer then performs (98) one or more event routines asso- 
ciated with this occurrence before proceeding to fetch the l 
next packet *^ 

The routines may include logging information about the J 
destination and source devices and the content of the packet j 
the time on which the event occurred, and a variety of other L lo^V^"^j 
information. The information may be sent to another process \ 
or device using an SNMP (simple network management J 
protocol) message or other mechanisms. 

Even though the hardware address of the backdoor may -s. 
be determined and reported using the method described 
above, it may be cumbersome for the LAN adrninistrator to 
use this information because the hardware addresses of the 
devices connected to the network medium may not be 
known. To simplify the administrator's work, a reverse 
address resolution protocol (RARP) server 100 (FIG. 2) may 
be used. The RARP server includes a table that permits it 
automatically to translate hardware network addresses to IP 
addresses which are typically well known by the adminis- 
trator. One of the event routines 98 may be to send the 
hardware address of the back door to the RARP server for 
resolution into the corresponding IP address. 

Similarly, building up table 88 may be a cumbersome job 
for the administrator who may not know the hardware 
addresses of the devices connected to the network medium. ( 
The table could be built dynamicall y using an ARP protoco l J 
on IP addresses^ 

An example of code which implements a packet scanner 
is set forth in Appendix A. 

Other embodiments are within the scope of the following 
claims. For example, the network protocol need not be IP 

The detennination of whether or not a packet is involved 
in an off-network communication need not be based on 
analysis of IP addresses in the packet In the case of a routing 
protocol (such as RIP), the packet scanner could watch for 
packets indicating that a non-authorized router on its net- 
work is advertising routes. In the case of a protocol (such as 
ICMP). the packet scanner could watch for a 'Yedirecf 
message which may be sent to force a redirection of a 
message to an unauthorized gateway. 
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/* + + APPENDIX A 

Copyright (c) 1996 Raptor Systems, Inc. All rights reserved. 

Permission to copy, modify, distribute, or sell this software or its 
documentation for any purpose is- hereby denied without specific, written 
prior permission from Raptor Systems Incorporated. 

Raptor Systems Incorporated disclaims all warranties with regard to* this 
sottware, including all implied warranties of merchantability and fitness, 
in no event shall Raptor Systems Incorporated be liable for any special, 
indirect or consequential damages or any damages whatsoever resulting from 
loss of use, data or profits, whether in an action of contract, negligence 
or other tortious action, arising out of or in connection with the use or 
performance of this software. 

Scan.c 

Abstract : 

Detecting Unauthorized Network Communications 
This- file contains SAMPLE CODE... 

associated with the implementation of the promiscuous mode 
WAN/Scan interface portion of the NT Firewall driver. 

This version only scans for IP-based "back -doors'* 

--♦/ 

#include "scan.h" /* macros, definitions, prototypes... */ 

static const IPADDRESS Broadcast Address - OxFFFFFFFFUL; 

/* 

* Begin code section. 

*/ 



/* 
* 

*/ 
UIKT 

VpnScan 



VpnScan is the entry-point from the code in our driver which is 
given the the look-ahead buffers from the lower (MAC) layer 



{ 

IN PVPN ADAPTER 
IN NDIS~MEDIDM 
IN PVOID 
IN HINT 



Adapter, 

MedialnUse, 

Data, 

DataLength 



NDIS_STATUS 

PETHERNET_HEADER 

PIP_HEACER 

IPADDRESS 

USHORT 



Status; 

EnetHeader; 

IpHeader; 

IpDstAddress; 

EnetProtocol; 
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UINT IpHeaderLength; 
UINT result; 

consc ND I S_PHYS I CAL_ADDRESSH_Accep t able = NDIS_PHYSICAL_ADDRESS_CONST ( - 1 , - 1) 

VPNDBG(VpnDbgIpSec, DbgPrint ("VPN: -->VpnScan \n") ; ) 

result - SCAN_KEEP; /* lets assume we want to keep it */ 

switch (MedialnUse) { 

case NdisMedium802_3 : 

BnetHeader » (PETHERNET HEADER) Data; 

BnetProtocol = * ( (PUSHORT7(&EnetHeader->EthProtocolType 10) } ) ,- 
break; 

case NdisMedium802_5 : 

// 

// In our receive code we built a contiguous buffer so we can 
// pass the sum of the header and data to other functions. 
// ' . 

BnetProtocol =- VpnTrFrameEtherType ( Data, DataLength) ; 
breaJc ; 

default : 

ASSERT { FALSE ) ; 
goto Done; 

} // End switch (MedialnUse) 

if (ETHER ARP PROTOCOL EnetProtocol) { 

// ~ " 

// Pass along ARP requests. 

yoto Done; 

if (ETHER IP PROTOCOL ! = EnetProtocol) { 
// " ~ 

// Don't handle anything but IP from here. 
// 

goto Done; 



if ( DataLength < MIN SCAN DATA LENGTH ) { 

// " 

// Don't have enough data to work with so don't attempt to do 
// anything with this frame. 

result - SCANJDROP; 
^ goto Done; ™ 

switch (MedialnUse) { 
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case NdisMedium802_3 : 

IpHeader « (PIP_HEADER) { { (PUCHAR) Data) + size of (ETHERNET HEADER) 
break; 

case NdisMedium802_5 : 

// 

// In our receive code we built a contiguous buffer so we can 
// pass the sum of the header and data to other functions. 

IpHeader - VpnTr Frame IpOf f sec ( Data, DataLength) ; 
if (NULL — IpHeader) { 
goto Done; 

break ; 

default : 

ASSERT (FALSE) ; 
goto Done; 
} // End switch (MedialnUse) 

/* get IP header length, using macro */ 
ipHeaderLength = 

(OINT) IP_HEADER_LENGTH ( IpHeader- >IpVersionAndHeaderLength) ; 

// 

// Check for valid IP Header Length, must be at least 20 bytes. 

if ( IpHeaderLength < sizeof (IP HEADER) ) { 
result - SCAN_DROP; 
goto Done; ™ 

// 

// Determine if this IP packet is to be scanned 

if (result - vpn_packet_is_routing protocol ( (unsigned char*) IpHeader) ) 
unsigned char* dptr; 

dptr m (unsigned char*) Data; /* point to mac */ 

d P tr ♦* 6; /# point to src addr * 

if ( vpn^packet_via_badguy< dptr)) { /* check' src mac addr 

*^ src address is not authorized gateway! 

int i; /* loop var ♦/ 

struct ipv4* ip; 

unsigned char mac [6]; 

unsigned char src [4]; * 

unsigned char dst (4] ; 

/* build mac logging buffer */ 
for (i-0; i<6; i++> 

raac(ij - *dptr++; 

/* build ip logging buffer */ 
ip - (struct ipv4*) IpHeader; 

dptr - (unsigned char*) &ip->ip_erc; /* pt to IP src *, 
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for (i=0; i<4; i++) { 

src(i] = *dptr; 

dst Ci) « * (dptr+4) ; 
^ dptr++; 

/* log something */ 

VPNDBG ( VpnDbgScanAlert, DbgPrint { 
"%s *d.%d.*d.%d->%d.%d.%d.%d %s %x: %x:%x: %x:%x:%x\n" , 
"SCAN: ALERT 3 - packet 
src{0], srctl], src(2j, src[3], 
dstfO], dst[l], dst (2], dst [3], 
"routing protocol by unauthorized gateway H , 
macCO], mac(l], mac [2], mac [3], mac [4), mac (53 
); > 

/* 

* pass packet to event -logger for 

* application layer reporting 
•/ 

savejpacket^for reporting ( Data); 

. ' 1 -• . 

// 

// Determine if this IP packet is to be scanned 

u 

if (result « vpn_packet_of f jprotected_net { (unsigned char*) IpHeader) ) 
unsigned char* dptr; 

dptr - (unsigned char*) Data; /* point to mac */ 

if ( <SRC_SUSPECT | DST_SUSPECT) result) { 

int i; /* loop var */ 

struct ipv4 * ip ; 

unsigned char sraac[6]; 

unsigned char dmac[6}; 

unsigned char src(4] ; 

unsigned char dat(4]; 

/* log something */ 

VPNDBG ( VpnDbgScanAlert, DbgPrint ( 

"SCAN: ALERT 2 - both IP addresses are external ! \n N ) ; 

if ( vpn_packet_via_badguy ( (dptr+6)) ) { 

VPNDBG ( VpnDbgScanAlert , DbgPrint ( 

"SCAN: ALERT 2 -arc MAC unauthorized gateway\n 

» "' , 

if ( vpn_packet_via badguyt (dptr)) J { 

VPNDBG ( VpnDbgScanAlert, DbgPrint ( 

■SCAN: ALERT 2 - dst MAC unauthorized gateway\i 

/* 

* pass packet to event logger for 

* application layer reporting 
*/ 

save^ packet^ f or_reporting ( Data) ; 
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/* build mac logging buffer */ 
for <i=0; . i<6; { 

dmac [i] = *dptr; 

smacfi] - * (dptr+6) 

dptr++ ; 

} 

/* build ip logging buffer */ > 
ip o (struct ipv4*) IpHeader; 

dptr o (unsigned char* ) &ip->ip_src; /* pt to IP src 
for (i=0; i<4; i++) { 

src[i] = *dptr; 

dst [i] = Mdptr+4) ; 

dptr++; 

> 

/* log something */ 

VPNDBG ( VpnDbgScanAlert, DbgPrint ( 
w %8 %d. *d.%d.%d->%d.*d.%d.*d (*X:%X:%X: %X: *X : %X->Vx: %X: %x: %X; %X: %x) \ 
"SCAN: ALERT 2 - packet n , 
src[0]. ( srctl], src(2] r src [3], 
dst [03, dst(l], dst [23, dst [3] , 

amacCO], smacUK smac[2), smac[3), smac[4], amac[5], 
dmac[0), droac[l] t dmac [2], dmac [3) , dmac (4], dmac [51 

); ) 

/* 

* pass packet to event logger for 

* application layer reporting 
>/ 

save_packet_for_reporting( Data); 



} 



goto cleanup; 



if (result — SRC_SUSPECT) 
dptr +- 6; 

if ( vpn^packet_via_badguy( dptr) ) { 

* address is not authorized gateway! 

*/ 

int i ; /* loop var */ 

struct ipv4* ip; 

unsigned char mac 16] 

unsigned char src (4 3 

unsigned char dst [43 

/* build mac logging buffer */ 
for (i-0; i<6; i++) 

macfij - *dptr++; 

/* build ip logging buffer */- 
ip - (struct ipv4 + ) IpHeader; " 

dptr = (unsigned char*) &ip->ip_src; /* pt to IP src 
for (i»0; i<4; i++) { 

srcfil o *dptr; 

dst [i3 - * (dptr+4 ) ; 

dptr**? 
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} 

/* log something */ 

VPNDBG ( VpnDbgScanAlert , DbgPrinc i 
"%s %d.%d_*d.Vd->%d.%d. Vd.%d %s %x: %x;%x: Vx: Vx : %x\n" . 
"SCAN: ALERT 1 - packet " , 
src[0], src[l], srcf2], src[3] , 
dst[0), dsttDr dst[2], dst[3), 

"via unauthorized gateway " , » 
mac[0] # mac[l], raac (2], mac [3 J, mac [4], mac [5] 
>; ) 

/* 

* pass packet to event logger for 

* application layer reporting 
*/ 

save_packet_for_reporting( Data) ; 



} 

cleanup: 



// 

// if packet not for me or beast, drop it 

// 

IpDstAddress - * ( (PIPADDRESS) ( tlpHeader- >IpDstAddress [0) ) ) ; 
// 

// If this IP packet is addressed to this gateway then pass it up. 
// NOTE: We don't check the IP checksum here because we want the IP 
// NOTE: statistics to catch this error. 
// 

if { IpDstAddress ==» Adapter- >IpAddr ess) { 

// IP Addressed to this station so pass it up. . . 

^ goto Done; 

if ( IpDstAddress BroadcastAddress) { 
// 

// IP Broadcast so pass it up. . . 

// 

goto Done; 

/* 

*^ else it isn't for me r so drop packet... 
result .= SCAN_DROP; * 



Done : 



VPNDBG (VpnDbglpSec, DbgPrint CVPN: <--VpnScan \n M ); ) 
return result ; 
) // End VpnScan 
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/* 

* global anchors for lookup tables 

struct scan_net* net_db head = NULL; 

struct scan_gate* gate_db_head = NULL; 

/#**+****+*++** ***************************#**#******#**********+*****#*****/ 

/* 

* For SAMPLE code, simple hard-coding 1 authorized gateway 
- * and 1 protected internal network 

*/ 
void * 

VpnScanlnit 0 

NDIS JSTATUS - status ; 

unsigned char* . new data; 

struct scanjiet* - my_net ; 

struct scan_gate* my gate; 

unsigned int size; 

const NDIS - PHYSICAL_ADDRESS H_Accep table « NDIS_PHYSICAL_ADDRESS_CONST ( -1, - 

VPHDBG(VfcnDbgIpSec, DbgPrint ("VPN: - ->VpnScanInit\n B ) ; ) 

/* 

build internal network database 

♦/ 

size - sizeof( *my_jaet) ; 

status « NdisAllocateMemory ( &new data, 

(unsigned int) size, 
0, 

M Acceptable 
)7 

if (NDIS_STATUS_SUCCESS t- status) { 

VPNDBGCVpnDbgScan, DbgPrint ("VPN: Memory ALLOC Failed (tunnel) \n 
return 0; 

} 

/* 

*^ 9 setup main tunnel structure * 

my_net = (struct scan net*) new data; 
nty_net->prev « NULL; *" ~ 
my_net->next - NULL; 

my_net->net * htonl (0x01020300) ; /* internal net 1.2.3.0 */ 

my_net->mask = htonl (Oxfffff f 00) ; 



** 
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* Link it into database 
*/ 

net_db_head = my_net; 
* * 

** build allowed Gateway database 

** . ♦ 

*/ 

size « eizeo£( *my_gate) ; 

status * NdisAllocateMemory ( &new_data, 

(unsigned int) size, 
0, 

H_Acceptable 
); 

if (NDIS_STATUS SUCCESS status) { 

VPNDBG<VpnDEgScan, DbgPrint {"VPN: Memory ALLOC Failed (tunnel) \n" 
^ return 0; 

/• 

* setup main tunnel structure 
V 

my_gate ■ (struct scan gate*) new_data; 
myjgate->prev - NULL; ~ 
my_gate->next = NULL; 

ray_gate->ip_addr = htonl (Ox040S0607J ; /* address 4.5.6.7 */ 

my_gate->mac_addr (0] = OxOB 

tny_gate->mac_addr [1] « 0x00 

my_gate- >mac_addr ( 2 ] « 0x20 

my_gate->mac addrl3] - 0x01 

my_gate - >mac~addr ( 4 ] - 0x02 

ray_gate->mac_addr [S] = 0x03 

/* 

* Link it into database 
*/ 

gate_db_head « ray_gate ; 

t 

VFNDBG(VpnDbgIpSec, DbgPrint ("VPN: <--VpnScanInit\n t *) ; ) 
return 0; 



int 

vpn_packet is_routing_protocol ( packet ) ' 
unsigned cHar* packet; 

struct ipv4* ip; 
unsigned char nextjiroto; 



It; 



int resu 

VPNDBG (VpnDbglpSec, 

DbgPrint ("VPN: - - >vpn_packet_is_routing_protocol\n" ) ; ) 
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/* 

•^retrieve next protocol from packet 

ip » (struct ipv4 *) packet ; 
nexcjproto ~ ip->ip_p; 

/* 

* SAMPLE 

* list of routing protocols you want to flag for attention 

* add protocols as desired. . . 

note: if you want to scan for RIP, scan for appropriate UDP traffic, 
if you want to scan for BGP, scan for appropriate TCP traffic. 



* 
* 
* 



if (next proto « IPPROTOJ3GP) { /* (3) Gateway- to-Gateway */ 

result « 1; /* ALERT (maybe), match on scan */ 

else if (next_proto IPPROTO_EGP) { /♦ (8) Exterior Gateway Protocol * 

result » l; /* ALERT (maybe), match on scan */ 

else if (hext_prjoto *» IPPROTO_IGP) { /* (9) private Interior Gateway */ 

result - l; * /# ALERT (maybe), match on scan */ 

else { 

result = 0; /# ok, no match on this scan */ 

VPNDBG (VpnDbglpSec, 

DbgPrint ("VPN: <--vpn^acket_is_routing_protocol\n") ; ) 

return ( result) ; 



} 



int 

vpn_packet_off_protected net ( packet J 
unsigned char* packet; " 

struct ipv4* ip ; 

unsigned long dst; /* Destination address - host order*/ 

unsigned long S rc; /* Source address - host order */ 

int arc stat; 

int dst"stat; 

int result ; 
struct scan_net* net; 

VPNDBG (VpnDbglpSec , 

DbgPrint ("VPN: - ->vpnjacket_off protect ed_net\ n" > ; ) 

/* 

* assume the worst 
*/ 

src_stat * SRC_SUSPECT; 
dst_stat o DST_SUSPECT ; 
result - SRC_SUSPECT | DST_SUSPECT; 

/* 

* retrieve addresses from packet 
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*/ 

ip = (struct ipv4*) packet; 
dst o ip->ip_dst; 
src = ip->ip~src; 



for (net a net_db_head; net ; net « net->next) 

if ((src » e 0x00000000) || (ere « Oxf f f f f f f f ) ) 

src scat « OK; 
if ((dst *=«~0x00000000) || (dst =- Oxf f f f f f f f > ) 

dst_stat = OK; 
if ( net->net =- (src & net->mask)) 

src_stat = OK; 
if ( net->net — <dst & net->mask)) 

dst_stat = OK; 
result = src_stat j dst_stat; 

if ( 0 « result) 
goto done; 



done : 

VPNDBG {VpnDbglpSec , ~ 

DbgPrint ("VPN: <--vpn_packet_off j?rotected_net\n" ) ; ) 

return result; 

} 



vpn_packet via_badguy< mac ) 
unsigned cKar*~mac; 

struct scan_gate* gate- 
unsigned char* gateway; 
int result; 

VPNDBG (VpnDbglpSec , 

DbgPrint ("VPN: -->vpn_packet_via_badguy\n" ) ; ) 

result « 1; /* assume badguy */ 

for (gate ■ gate_db_head; gate ; gate - gate->next) { 
gateway = (unsigned char*) &gate->mac_addr [0J ; 

if ( ( * (unsigned short*) (gateway) =- * (unsigned short*) (mac) ) && 
( *(unsigned short*) (gateway+2) »« * (unsigned short*) (mac+2) ) 
( * (unsigned short*) (gateway+4 ) * (unsigned short*) (mac+4) ) ) 
result « 0; /* found a registered gateway, so he is OK */ 

goto done; 

} 

done : 

VPNDBG (VpnDbglpSec , DbgPrint ("VPN: <--vpn_packet_viaJ>adguy\n"> ; ) 
return ( result ); /* not found, must be a badguy... */ 
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What is claimed is: 

1. A method for use with devices (hat are coupled by a 
communication medium to form an internal packet network, 
at least one of the devices not being an authorized conduit 
for communication with external devices that are not part of 5 
the internal packet network, the method comprising 

observing packets passing on the medium. 

based on the observation, detecting packets that pass 
between the internal packet network and one of the 
external devices via one of the devices that is part of the 10 
internal network, and 

for detected packets associated with communication with 
the external device, determining if the one device via 
which the packets pass is an authorized conduit for 
communication with external devices. 15 

2. The method of claim 1 in which the detecting comprises 
comparing address information in the packets with 

address information associated with devices that arc 
part of the internal packet network to determine if the ^ 
packet involves communication only between devices 
that are part of the internal packet network. 

3. The method of claim 2 in which the address information 
comprises logical network addresses. 

4. The method of claim 2 in which the logical network ^ 
addresses comprise IP addresses. 

5. The method of claim 2 further comprising storing the 
address information associated with devices that are part of 
the internal packet network in a look-up table. 

6. The method of claim 1 in which the determining 
comprises 

examining hardware addresses in the packets. 

7. The method of claim 6 in which the hardware addresses 
comprise unique hardware addresses of network interface 
cards in the devices. 

8. The method of claim 1 further comprising 
comparing address information in the packets with 

address information associated with the devices that are 
authorized conduits for communication with external 
devices. 40 

9. The method of claim 8 further comprising storing the 
address information associated with the devices that are 
authorized conduits in a look-up table. 

10. The method of claim 1 in which at least one of the 
devices of the internal packet network is an authorized 45 
conduit for communication with external devices that are not 
part of the internal packet network. 

11. The method of claim 1 further comprising storing 
packets temporarily in a look-ahead buffer. 

12. The method of claim 1 further comprising reporting 50 
information about the non-authorized communication. 

13. A method for reducing back door packet communi- 
cation between a device on a network that is not an autho- 
rized conduit for communication with external devices that 
are outside of the network and a device outside the network 55 
comprising 

detecting packets that pass between the network and the 
device outside the network via the device on the 
network, and 

identifying packets among the detected packets that are 60 
sent or received by the device on the network that is not 
authorized for communication with devices outside the 
network. 

14. Apparatus for use in reducing packet communication 
between a device on a network that is not an authorized 65 
conduit for communication with devices outside the network 
and a device outside the network comprising 
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a scanner connected to observe packets passing on the 
network, and 

an analyzer that determines if one of the packets includes 
address information indicating that communication is 
occurring with the device that is not an authorized 
conduit for communication with devices outside the 
network and the external device. 

15. A method for use with devices that are coupled by a 
communication medium to form an internal packet network, 
none of the devices being an authorized conduit for com- 
munication with external devices that are not part of the 
internal packet network, the method comprising 

observing network address information in packets passing 
on the medium. 

based on the observed network address information, 
detecting packets intended to pass from the internal 
packet network to the external device via one of the 
devices that is part of the internal packet network, and 

raising an alarm with respect to packets intended for 
communication with an external device. 

16. The method of claim 1 in which the determining 
comprises watching for packets indicating that a non- 
authorized device is advertising routes. 

17. The method of claim 1 in which the determining 
comprises watching for redirect messages being sent by a 
non-authorized device to redirect traffic to an unauthorized 
gateway. 

18. A method for use with devices that are coupled by a 
communication medium to form an internal message 
network, at least one of the devices not being an authorized 
conduit far communication with external devices that are not 
part of the internal message network, the method comprising 

observing messages passing on the medium, 
based on the observation, detecting messages that pass 
between the internal packet network and one of the 
external devices via one of the devices that is part of the 
internal packet network, and 
for detected messages associated with communication 
with the external device, detenmning if the one device 
via which the packets pass is an authorized conduit for 
communication with external devices. 

19. A method for use with devices that are coupled by a 
communication medium to form an internal packet network, 
at least one of the devices not being an authorized conduit 
for communication with external devices that are not part of 
the internal packet network, the method comprising 

observing packets passing on the medium. 

based on the observation, detecting packets that pass 
between the internal packet network and one of the 
external devices via one of the devices that is part of the 
internal network by comparing the IP addresses of the 
packets with the IP addresses of devices on the internal 
packet network. 

for detected packets associated with communication with 
the external device, determining if the one device via 
which the packets pass is an authorized conduit for 
communication with external devices by comparing the 
hardware addresses of the packets with hardware 
addresses that correspond to devices that are authorized 
conduits, and 

for packets whose hardware addresses do not correspond 
to devices that are authorized conduits, reporting infor- 
mation about the non-authorized communication. 
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